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Abstract 

We show how a set of building blocks can be used to construct 
programming language interpreters, and present implemen- 
tations of such building blocks capable of supporting many 
commonly known features, including simple expressions, 
three different function call mechanisms (call-by-name, call- 
by-value and lazy evaluation), references and assignment, 
nondeterminism, first-class continuations, and program trac- 
ing. 

The underlying mechanism of our system is monad trans- 
formers, a simple form of abstraction for introducing a wide 
range of computational behaviors, such as state, I/O, con- 
tinuations, and exceptions. 

Our work is significant in the following respects. First, 
we have succeeded in designing a fully modular interpreter 
based on monad transformers that includes features miss- 
ing from Steele's, Espinosa's, and Wadler's earlier efforts. 
Second, we have found new ways to lift monad operations 
through monad transformers, in particular difficult cases not 
achieved in Moggi's original work. Third, we have demon- 
strated that interactions between features are reflected in 
liftings and that semantics can be changed by reordering 
monad transformers. Finally, we have implemented our 
interpreter in Gofer, whose constructor classes provide just 
the added power over Haskell's type classes to allow precise 
and convenient expression of our ideas. This implementa- 
tion includes a method for constructing extensible unions 
and a form of subtyping that is interesting in its own right. 

1 Introduction and Related Work 

This paper discusses how to construct programming lan- 
guage interpreters out of modular components. We will 
show how an interpreter for a language with many features 
can be composed from building blocks, each implementing 
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a specific feature. The interpreter writer is able to specify 
the set of incorporated features at a very high level. 

The motivation for building modular interpreters is to 
isolate the semantics of individual programming language 
features for the purpose of better understanding, simplifying, 
and implementing the features and their interactions. The 
lack of separability of traditional denotational semantics [19] 
has long been recognized. Algebraic approaches such as 
Mosses' action semantics [16], and related efforts by Lee 
[13], Wand [23], Appel & Jim [1], Kelsey & Hudak [11], and 
others, attempt to solve parts of this problem, but fall short 
in several crucial ways. 1 

A ground-breaking attempt to better solve the overall 
problem began with Moggi's [15] proposal to use monads to 
structure denotational semantics. Wadler [21] popularized 
Moggi's ideas in the functional programming community 
by showing that many type constructors (such as List) were 
monads and how monads could be used in a variety of 
settings, many with an "imperative" feel (such as in Peyton 
Jones & Wadler [17]). Wadler's interpreter design, however, 
treats the interpreter monad as a monolithic structure which 
has to be reconstructed every time a new feature is added. 
More recently, Steele [18] proposed pseudomonads as a way 
to compose monads and thus build up an interpreter from 
smaller parts, but he failed to properly incorporate important 
features such as an environment and store, and struggled 
with restrictions in the Haskell [7] type system when trying 
to implement his ideas. In fact, pseudomonads are really 
just a special kind of monad transformer, first suggested by 
Moggi [15] as a potential way to leave a "hole" in a monad 
for further extension. 

Returning to Moggi's original ideas, Espinosa [4] nicely 
formulated in Scheme a system called Semantic Lego — the 
first modular interpreter based on monad transformers — 
and laid out the issues in lifting. Espinosa's work reminded 
the programming language community (including us) — 
who had become distracted by the use of monads — that 
Moggi himself, responsible in many ways for the interest in 
monadic programming, had actually focussed more on the 
importance of monad transformers. 

We begin by realizing the limitations of Moggi's frame- 
work and Espinosa's implementation, in particular the diffi- 
culty in dealing with complicated operations such as callcc, 
and investigate how common programming language fea- 

1 Very recently, Cartwright and Felleisen [3] have independently proposed 
a modular semantics emphasizing a direct semantics approach, which seems 
somewhat more complex than ours; the precise relationship between the 
approaches is, however, not yet clear. 
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Figure 1: A modular interpreter 





tures interact with each other. In so doing we are able to 
express more modularity and more language features than in 
previous work, solving several open problems that arose not 
only in Moggi's work, but in Steele's and Espinosa's as well. 
Our work also shares results with Jones and Duponcheel's 
[10] work on composing monads. 

Independently, Espinosa [5] has continued working on 
monad transformers, and has also recognized the limitations 
of earlier approaches and proposed a solution quite different 
from ours. His new approach relies on a notion of "higher- 
order" monads (called situated monads) to relate different 
layers of monad transformers, and he has investigated the 
semantic implications of the order of monad transformer 
composition. It is not yet clear how his new approach relates 
to ours. 

We use Gofer [8] syntax, which is very similar to Haskell's, 
throughout the paper. We choose Gofer over Haskell because 
of its extended type system, and we choose a functional 
language over mathematical syntax for three reasons: (1) 
it is just about as concise as mathematical syntax, 2 (2) 
it emphasizes the fact that our ideas are implementable 
(and thus have been debugged!), and (3) it shows how the 
relatively new idea of constructor classes [9] can be used 
to represent some rather complex typing relationships. Of 
course, monads can be expressed in a variety of other 
(higher-order) programming languages, in particular SML 
[14], whose type system is equally capable of expressing 
some of our ideas. The system could also be expressed 
in Scheme, but of course we would then lose the benefits 
of strong static type-checking. Our Gofer source code is 
available via anonymous ftp from nebula.cs.yale.edu in the 
directory pub /y ale- fp /modular-interpreter. 

To appreciate the extent of our results, Figure 1 gives the 
high-level definition of an interpreter, which is constructed 
in a modular way, and supports arithmetic, three different 
kinds of functions (call-by-name, call-by-value, and lazy), 
references and assignment, nondeterminism, first-class con- 
tinuations, and tracing. The rest of the paper will provide 
the details of how the type declarations expand into a full 
interpreter and how each component is built. For now just 
note that OR is equivalent to the domain sum operator, and 
Term, Value and InterpM denote the source-level terms, run- 
time values, and supporting features (which can be regarded 
as the run-time system), respectively, hit and Fun are the 
semantic domains for integers and functions. TermA, TermF, 
etc. are the abstract syntax for arithmetic terms, function 

2 Although (for lack of space) we do not include any proofs, all constructs 
(monads, monad transformers and liftings) expressed as Gofer code have 
been verified to satisfy the necessary properties stated in this paper. 



expressions, etc. Type constructors such as StateT and ContT 
are monad transformers; they add features, and are used to 
transform the monad List into the monad InterpM used by 
the interpreter. 

To see how Term, Value, and InterpM constitute to modular 
interpreters, in the next section we will walk through some 
simple examples. 

2 An Example 

A conventional interpreter maps, say, a term, environment, 
and store, to an answer. In contrast, a monadic interpreter 
such as ours maps terms to computations, where the details 
of the environment, store, etc. are "hidden". Specifically: 

interp :: Term — » InterpM Value 

where "InterpM Value" is the interpreter monad of final 
answers. 

What makes our interpreter modular is that all three 
components above — the term type, the value type, and the 
monad — are configurable. To illustrate, if we initially wish 
to have an interpreter for a small arithmetic language, we 
can fill in the definitions as follows: 

type Value = OR Int () 
type Term = TermA 
type InterpM = ErrorT Id 

The first line declares the answer domain to be the union 
of integers and the unit type (used as the base type). The 
second line defines terms as TermA, the abstract syntax for 
arithmetic operations. The final line defines the interpreter 
monad as a transformation of the identify monad Id. The 
monad transformer ErrorT accounts for the possibility of 
errors; in this case, arithmetic exceptions. 

At this point the interpreter behaves like a calculator: 3 

> ((1 + 4)* 8) 
40 

> (3/0) 

ERROR: divide by 0 

Now if we wish to add function calls, we can extend the 
value domain with function types, add the abstract syntax 
for function calls to the term type, and apply the monad 
transformer EnvT to introduce an environment Env. 

type Value = OR Int (OR Fun ()) 
type Term = OR TermF TermA 
type InterpM = EnvT Env (ErrorT Id) 

3 For lack of space, we omit the details of parsing and printing. 
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Here is a test run: 

> a\x.(x+i))7) 
a 

> (a + 4) 

ERROR: unbound variable: x 

By adding other features, we can arrive at (and go beyond) 
the interpreter in Figure 1. In the process of adding new 
source-level terms, whenever a new value domain (such as 
Boolean) is needed, we extend the Value type, and to add a 
new semantic feature (such as a store or continuation), we 
apply the corresponding monad transformer. 

Why monads? In a sense, monads are nothing more than 
a good example of data abstraction. But they just happen 
to be a particularly good abstraction, and by using them in 
a disciplined (and appropriate) way, we generally obtain 
well-structured, modular programs. In our application, they 
are surprisingly useful for individually capturing the essence 
of a wide range of programming language features, while 
abstracting away from low-level details. Then with monad 
transformers we can put the individual features together, 
piece-by-piece in different orders, to create full-featured 
interpreters. 

3 The Constructor Class System 

For readers not familiar with the Gofer type system (in 
particular, constructor classes [9]), this section provides a 
motivating example. 

Constructor classes support abstraction of common fea- 
tures among type constructors. Haskell, for example, pro- 
vides the standard may function to apply a function to each 
element of a given list: 

map :: (a — » b) — » [a] — » [b] 

Meanwhile, we can define similar functions for a wide range 
of other datatypes. For example: 

data Tree a = Leaf a 

; Node (Tree a) (Tree a) 

mapTree :: (a — > b) — > Tree a — > Tree b 
mapTree f (Leaf x) = Leaf (fx) 

mapTree f (Node I r) = Node (mapTree f I) (mapTree f r) 

The mapTree function has similar type and functionality to 
those of map. With this in mind, it seems a shame that we 
have to use different names for each of these variants. Indeed, 
Gofer allows type variables to stand for type constructors, on 
which the Haskell type class system has been extended to 
support overloading. To solve the problem with map, we can 
introduce a new constructor class Functor (in a categorical 
sense): 

class Functor f where 

map :: (a->b)->fa->fb 

Now the standard list (List) and the user-defined type con- 
structor Tree are both instances of Functor: 

instance Functor List where 
map f [ ] = [ ] 

map f (x :xs) = fx: map f xs 



instance Functor Tree where 
map f (Leaf x) = Leaf (fx) 
map f (Node I r) = Node (map f I) (map f r) 

In building modular interpreters, we will find constructor 
classes extremely useful for dealing with multiple instances 
of monads and monad transformers (which are all type 
constructors). 

4 Extensible Union Types 

We begin with a discussion of a key idea in our framework: 
how values and terms may be expressed as extensible union 
types. (This facility has nothing to do with monads.) 

The disjoint union of two types is captured by the 
datatype OR. 

data ORab = La \ Rb 

where L and R are used to perform the conventional injection 
of a summand type into the union; conventional pattern- 
matching is used for projection. However, such injections 
and projections only work if we know the exact structure 
of the union; in particular, an extensible union may be 
arbitrarily nested, and we would like a single pair of injection 
and projection functions to work on all such constructions. 

To achieve this, we define a type class to capture the 
summand /union type relationship, which we refer to as a 
"subtype" relationship: 

class SubType sub sup where 

in] :: sub — > sup - - injection 

prj :: sup — > Maybe sub - - projection 

data Maybe a = Just a \ Nothing 

The Maybe datatype is used because the projection function 
may fail. We can now express the relationships that we 
desire: 

instance SubType a (OR a b) where 

in) = L 

prj (L x) = Just x 
prj _ = Nothing 

instance SubType a b =>• SubType a (OR c b) where 

in] = R ■ in] 

prj (R a) = prj a 
prj _ = Nothing 

Now we can see, for example, how the Value domain 
used in the interpreter example given earlier is actually 
constructed: 

type Value = OR Int (OR Fun ()) 

type Fun = InterpM Value — > InterpM Value 

With these definitions the Gofer type system will infer that Int 
and Function are both "subtypes" of Value, and the coercion 
functions inj and prj will be generated automatically. 4 (Note 
that the representation of a function is quite general — it 
maps computations to computations. As will be seen, this 
generality allows us to model both call-by-name and call-by- 
value semantics.) 

We should point out here that most of the typing problems Steele 
encountered disappear with the use of our extensible union types; in 
particular, there is no need for Steele's "towers" of datatypes. 
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5 The Interpreter Building Blocks 

As in the example of Section 2, the Term type is also 
constructed as an extensible union (of subterm types). We 
define additionally a class InterpC to characterize the term 
types that we wish to interpret: 

class InterpC t where 

interp :: t — > InterpM Value 

The behavior of interp on unions of terms is given in the 
obvious way: 

instance {InterpC t\, InterpC t?) =>• 

InterpC (OR t\ t%) where 

interp (L t) = interp t 
interp (R t) = interp t 

The interp function mentioned in the opening example is just 
the method associated with the top-level type Term. 

In the remainder of this section we define several repre- 
sentative interpreter building blocks, each an instance of class 
InterpC and written in a monadic style. We will more for- 
mally define monads later, but for now we note that the 
interpreter monad InterpM comes equipped with two basic 
operations: 

unit :: a — > InterpM a 

bind :: InterpM a — > (a — > InterpM b) — > InterpM b 

Intuitively InterpM a denotes a computation returning a 
result of type a. "Unit x" is a null computation that just 
returns x as result, whereas "m 'bind' k" runs m and passes 
the result to the rest of the computation k. As will be seen, 
besides unit and bind, each interpreter building block has 
several other operations that are specific to its purpose. 

5.1 The Arithmetic Building Block 

Our (very tiny) arithmetic sublanguage is given by: 

data TermA = Num Int 

I Add Term Term 

whose monadic interpretation is given by: 

instance InterpC TermA where 
interp (Num x) = unitlnj x 
interp (Add x y) = interp x 'bindPrj' \i — > 
interp y 'bindPrj' \ j — » 
unitlnj ((i + j) :: Int) 

unitlnj = unit ■ inj 

m 'bindPrj' k = 

m 'bind' \a — » 

case (prj a) of 

Just x — > k x 

Nothing — » err "run-time type error" 

err :: String — » InterpM a - - defined later 

Note the simple use of inj and prj to inject/ project the integer 
result into/ out of the Value domain, regardless of how Value 
is eventually defined (unitlnj and bindPrj make this a tad 
easier, and will be used later as well). Err is an operation for 
reporting errors to be defined later. 



5.2 The Function Building Block 

Our "function" sublanguage is given by: 

data TermF = Var Name 

j LambdaN Name Term - - cbn 

j LambdaV Name Term - - cbv 

I App Term Term 

which supports two kinds of abstractions, one for call-by- 
name, the other for call-by-value. 

We assume a type Env of environments that associates 
variable names with computations (corresponding to the 
"closure" mode of evaluation [2]), and that has two opera- 
tions: 

lookupEnv :: Name — » Env — > Maybe (InterpM Value) 
extendEnv :: (Name, InterpM Value) — > Env — > Env 
type Name = String 

In addition, we will define later two monadic operations, 
rdEnv and inEnv, that return the current environment and 
perform a computation in a given environment, respectively: 

rdEnv :: InterpM Env 

inEnv :: Env — » InterpM a — » InterpM a 

The interpretation of the applicative sublanguage is then 
given in Figure 2. 

The difference between call-by-value and call-by-name 
is clear: the former reduces the argument before evaluating 
the function body, whereas the latter does not. In a function 
application, the function itself is evaluated first, and bindPrj 
checks if it is indeed a function. The computation of e2 
is packaged up with the current environment to form a 
closure, which is then passed to /. We could just as easily 
realize dynamic scoping by passing not the closure, but the 
computation of ei alone. 

When applying a call-by-value function, we build a com- 
putation which gets evaluated immediately upon entering 
the function body. Although semantically correct, this does 
not correspond to an efficient implementation. In practice, 
however, we expect that the presence of some kind of type 
information or a special syntax for call-by-value application 
will enable us to optimize away this overhead. 

We note that Steele felt it unsatisfactory that his inter- 
preter always had an environment argument, even though it 
was only used in the function building block. By abstracting 
environment-related operations as two functions (inEnv and 
rdEnv), we achieve exactly what Steele wished for. 

5.3 The References and Assignment Building Block 

A sublanguage of references and assignment is given by: 

data TermR = Ref Term 
| Deref Term 
| Assign Term Term 

Given a heap of memory cells and three functions for 
managing it: 

allocLoc :: InterpM hoc 

lookupLoc :: hoc — > InterpM Value 

updateLoc :: (hoc, InterpM Value) — > InterpM () 

type hoc = Int 

we can then give an appropriate interpretation to the new 
language features: 
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instance InterpC TermF where 

interp (Var v) = rdEnv 'bind' \env - 



interp (LambdaN s t) 
interp (LambdaV s t) 

interp (App ei e2) 



case lookupEnv v env of 
fust val — > val 

Nothing — > err ( "unbound variable: " ++ v) 
rdEnv 'bind' \env — > 

unitlnj (\arg — > inEnv (extendEnv (s, arg) env) (interp t)) 

rdEnv 'bind' \env — » 

unitlnj (\arg — > arg 'bind' \v — > 

inEnv (extendEnv (s, unit v) env) (interp t)) 
interp e\ 'bindPrj' \f — > 
rdEnv 'bind' \env — > 
f (inEnv env (interp e2)) 



Figure 2: The function building block 



instance InterpC TermR where 
interp (Refx) = 

interp x 'bind' \val — > 

allocLoc 'bind' \loc — » 

updateLoc (loc, unit val) 'bind' \_ — > 

unitlnj loc 

interp (Deref x) = 

interp x 'bindPrj' \loc — > 
lookupLoc loc 

interp (Assign Ihs rhs) = 

interp Ihs 'bindPrj' \loc — > 
interp rhs 'bind' \val — > 
updateLoc (loc, unit val) 'bind' \_ — > 
unit val 

5.4 A Lazy Evaluation Building Block 

Using this same heap of memory cells for references, we can 
implement "lazy" abstractions: 

data TermL = LambdaL Name Term 

whose operational semantics implies "caching" of results. 

instance InterpC TermL where 
interp (LambdaL s t) = 
rdEnv 'bind' \env — » 
unitlnj (\arg — > 

allocLoc 'bind' \loc — > 

let thunk = arg 'bind' \v — > 

updateLoc (loc, unit v) 'bind' \_ — > 
unit v 

in 

updateLoc (loc, thunk) 'bind' \_ — > 
inEnv (extendEnv (s , lookupLoc loc) env) 
(interp t j) 

Upon entering a lazy function, the interpreter first allocates 
a memory cell and stores a thunk (updatable closure) in it. 
When the argument is first evaluated in the function body, 
the interpreter evaluates the thunk and stores the result back 
into the memory cell, overwriting the thunk itself. 



5.5 A Program Tracing Building Block 

Given a function: 

write :: String — > InterpM () 

which writes a string output and continues the computation, 
we can define a "tracing" sublanguage, which attaches labels 
to expressions which cause a "trace record" to be invoked 
whenever that expression is evaluated: 

data TermT = Trace String Term 

instance InterpC TermT where 
interp (Trace I t) = 

write ("enter " ++ I) 'bind' \_ — » 
interp t 'bind' \v — > 

write ("leave " ++ I ++ " with:" ++ show v) 'bind' \_ — > 
unit v 

Here we see that some of the features in Kishon et al.'s 
system [12] are easily incorporated into our interpreter. 

5.6 The Continuation Building Block 

First-class continuations can be included in our language 
with: 

data TermC = CallCC 
Using the callcc semantic function (to be defined later): 

callcc :: ((a — > InterpM b) — > InterpM a) — > InterpM a 

we can give an interpretation for CallCC: 

instance InterpC TermC where 
interp CallCC = unitlnj (\f — > 
/ 'bindPrj' \f 

callcc (\k (/' (unitlnj (\a a 'bind' k))))) 

CallCC is interpreted as a (strict) builtin function. Interp in 
this case does nothing more than inject and project values to 
the right domains. 
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Feature 


Function 


Error handling 


err :: String — » InterpM a 


Nondeterminism 


merge :: [InterpM a] — » InterpM a 


Environment 


rdEnv :: InterpM Env 
inEnv :: Env — > InterpM a — > InterpM a 


Store 


allocLoc :: InterpM hit 
lookupLoc :: Int — > InterpM Value 
updateLoc :: (Jnf, InterpM Value) — » InterpM Int 


String output 


write :: String — » InterpM () 


Continuations 


caWcc :: ((a — » InterpM b) — » InterpM a) — » InterpM a 



Table 1: Monad operations used by the interpreter 



5.7 The Nondeterminism Building Block 

Our nondeterministic sublanguage is given by: 

data TermN = Amb [Term] 
Given a function: 

merge :: [InterpM a] — » InterpM a 

which merges a list of computations into a single (nondeter- 
ministic) computation, nondeterminism interpretation can 
be expressed as: 

instance InterpC TermN where 

interp (Amb t) = merge (map interp t) 

6 Monads With Operations 

As mentioned earlier, particular monads have other opera- 
tions besides unit and bind. Indeed, from the last section, it 
is clear that operations listed in Table 1 must be supported. 

If we were building an interpreter in the traditional way, 
now is the time to set up the domains and implement the 
functions listed in the table. The major drawback of this 
monolithic approach is that we have to take into account all 
other features when we define an operation for one specific 
feature. When we define callcc, for example, we have to 
decide how it interacts with the store and environment etc. 
And if we later want to add more features, the semantic 
domains and all the functions in the table will have to be 
updated. 

Monad transformers, on the other hand, allow us to individ- 
ually capture the essence of language features. Furthermore, 
the concept of lifting allows us to account for the interactions 
between various features. These are the topics of the next 
two sections. 

To simplify the set of operations somewhat, we note that 
both the store and output (used by the tracer) have to do 
with some notion of state. Thus we define allocLoc, lookupLoc, 
updateLoc, and write in terms of just one function: 

update :: (s — > s) — > InterpM s 

for some suitably chosen s. We can read the state by passing 
update the identity function, and change the state by passing 
it a state transformer. For example: 

write msg = update (\ sofar — > sofar ++ msg) 
'bind' \_ — > unit () 



7 Monad Transformers 

To get an intuitive feel for monad transformers, consider 
the merging of a state monad with an arbitrary monad, an 
example adapted from Jones's constructor class paper [9]: 

type StateT s m a = s — > m (s,a) 

Note that the type variable m above stands for a type 
constructor, a fact automatically determined by the Gofer 
kind inference system. It turns out that if m is a monad, so 
is "StateT s m". 5 "StateT s" is thus a monad transformer. 
For example, if we substitute the identity monad: 

type Ida = a 

for m in the above monad transformer, we arrive at: 

StateT s Id a = s — > Id (s,a) 
= s — > (s, a) 

which is the standard state monad found, for example, in 
Wadler's work [21]. 

The power of monad transformers is two-fold. First, they 
add operations (i.e. introduce new features) to a monad. The 
StateT monad transformer above, for example, adds state s to 
the monad it is applied to, and the resulting monad accepts 
update as a legitimate operation on it. 

Second, monad transformers compose easily. For exam- 
ple, applying both "StateT s" and "StateT t" to the identity 
monad, we get: 

StateT t (StateT s Id) a = t (StateT s Id) (t, a) 

= t -> s -> (s, (t,a)) 

which is the expected type signature for transforming both 
states s and t. The observant reader will note, however, 
an immediate problem: in the resulting monad, which state 
does update act upon? In general, this is the problem of 
lifting monad operations through transformers, and will 
be addressed in detail later. But first we define monads 
and monad transformers more formally, and then describe 
monad transformers covering the features listed in Section 
5. 

We can formally define monads as follows: 

In fact "StateT s m" is only legal in the current version of Gofer if StateT 
is a datatype rather than a type synonym. This does not limit our results, 
but does introduce superfluous data constructors that slightly complicate 
the presentation, so we will use type declarations as if they worked as data 
declarations. 
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class Monad m where 
unit :: a — > m a 
bind :: m a — > (a — > m b) — > m b 

map :: (a — » b) — » m a — » m b 
join :: m (m a) — > m a 

map f m = m 'bind' \a — » wwzf (/ a) 
join z = z 'bind' id 

The two functions map and join, together with unit provide 
an equivalent definition of monads, but are easily defined 
(as default methods) in terms of bind and unit. 

To be a monad, bind and unit must satisfy the well-known 
Monad Laws [21]: 
Left unit: 

(unit a) 'bind' k = k a 

Right unit: 

m 'bind' unit = m 

Associativity: 

m 'bind' \a — > (k a 'bind' h) = (m 'bind' k) 'bind' h 

We define a monad transformer as any type constructor t 
such that if m is a monad (based on the above laws), so 
is "t m" . We can express this (other than the verification 
of the laws, which is generally undecidable) using the two- 
parameter constructor class MonadT: 

class (Monad m, Monad (t ra)) =>• MonadT t ra where 
lift :: ra a — > t ra a 

The member function lift embeds a computation in monad 
m into monad "t m" . Furthermore, we expect a monad 
transformer to add features, without changing the nature of 
an existing computation. We introduce Monad Transformer 
Laws to capture the properties of lift: 

lift ■ unitm = unittm 
lift (m 'bindm' k) = lift ra 'bind tm ' (lift ■ k) 

The above laws say that lifting a null computation results 
in a null computation, and that lifting a sequence of com- 
putations is equivalent to first lifting them individually, and 
then combining them in the lifted monad. 

Specific monad transformers are described in the remain- 
der of this section. Some of these (StateT, ContT, and ErrorT) 
appear in an abstract form in Moggi's note [15]. The envi- 
ronment monad is similar to the state reader by Wadler [22]. 
The state and environment monad transformers are related to 
ideas found in Jones and Duponcheel's [9] [10] work. 

7.1 State Monad Transformer 

Recall the definition of state monad transformer StateT: 

type StateT s m a = s — > ra (s,a) 

Using instance declarations, we now wish to declare both 
that "StateT s m" is a monad (given m is a monad), and that 
"StateT s" is a monad transformer (for each of the monad 
transformers defined in subsequent subsections, we will do 
exactly the same thing). 

First, we establish the monad definition for "StateT s m" , 
involving methods for unit and bind: 



instance Monad ra =>• Monad (StateT s ra) where 
unit x = \s — > unit (s, x) 
m 'bind' k = \so-> m so 'bind' \(s\,a) — > 
k a s\ 

Note that these definitions are not recursive; the constructor 
class system automatically infers that the bind and unit 
appearing on the right are for monad m. 

Next, we define "StateT s" as a monad transformer: 

instance (Monad m, Monad (StateT s m)) 

MonadT (StateT s) m where 
lift m = \s — > m 'bind' \x — > unit (s, x) 

Note that lift simply runs m in the new context, while 
preserving the state. 

Finally, as explained earlier, a state monad must support 
the operation update. To keep things modular, we define a 
class of state monads: 

class Monad m StateMonad s m where 
update :: (s — > s) — > m s 

In particular, "StateT s" transforms any monad into a state 
monad, where "update f" applies / to the state, and returns 
the old state: 

instance Monad m StateMonad s (StateT s m) where 
update f = \s — > unit (f s, s) 

7.2 Environment Monad Transformer 

"EnvT r" transforms any monad into an environment monad. 
The definition of bind tells us that two subsequent compu- 
tation steps run under the same environment r. (Compare 
this with the state monad, where the second computation 
is run in the state returned by the first computation.) Lift 
just performs a computation — which cannot depend on the 
environment — and ignores the environment. InEnv ignores 
the environment carried inside the monad, and performs the 
computation in a given environment. 

type EnvT r m a = r — > m a 

instance Monad m Monad (EnvT r m) where 
unit a = \r — > unit a 

m 'bind' k = \r — > m r 'bind' \a — > k a r 

instance (Monad m, Monad (EnvT r m)) 

MonadT (EnvT r) m where 
lift m = \r — > m 

class Monad m EnvMonad env m where 
inEnv :: env — > m a — > m a 
rdEnv :: m env 

instance Monad m EnvMonad r (EnvT r m) where 
inEnv r m = \_ — > m r 
rdEnv = \r — > unit r 

7.3 Error Monad Transformer 

Monad Error completes a series of computations if all suc- 
ceed, or aborts as soon as an error occurs. The monad 
transformer ErrorT transforms a monad into an error monad. 

data Error a = Ok a \ Error String 
type ErrorT m a = m (Error a) 
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instance Monad m =>• Monad (ErrorT m) where 
unit = unit ■ Ok 

m 'bind' k = 

m 'bind' \a — > 
case a of 

(Ok x) — > k x 

(Error msg) — > unit (Error msg) 

instance (Monad m, Monad (ErrorT m)) =>• 

MonadT ErrorT m where 

lift = map unit 

class Monad m =>• ErrMonad m where 
err :: String — > m a 

instance Monad m =>• ErrMonad (ErrorT m) where 
err = unit ■ Error 

7.4 Continuation Monad Transformer 

We define the continuation monad transformer as: 
type ContT ans ma = (a — > m ans) — > m ans 

instance Monad m =>• Monad (ContT ans m) where 
unit x = \k — » k x 

m 'bind' f = \k — > m (\a -> f a k) 

ContT introduces an additional continuation argument (of 
type "a — > m ans"), and by the above definitions of unit and 
bind, all computations in monad "ContT ans m" are carried 
out in a continuation passing style. 

Lift for "Cont ans m" turns out to be the same as bind for 
m. (It is easy to see this from the type signature.) "Callcc 
f" invokes the computation in/, passing it a continuation 
that once applied, throws away the current continuation 
(denoted as "_") and invokes the captured continuation k. 

instance (Monad m, Monad (ContT ans m)) =>• 

MonadT (ContT ans) m where 

lift = bind 

class Monad m =>• ContMonad m where 
callcc :: ((a —>mb)—>ma)—>ma 

instance Monad m =>• ContMonad (ContT ans m) where 
callcc f = \k f (\a \_ k a) k 

7.5 The List Monad 

Jones and Duponcheel [10] have shown that lists compose 
with special kinds of monads called commutative monads. It 
is not clear, however, if lists compose with arbitrary monads. 
Since many useful monads (e.g. state, error and continuation 
monads) are not commutative, we cannot define a list monad 
transformer — one which adds the operation merge to any 
monad. 

Fortunately, every other monad transformer we have 
considered in this paper takes arbitrary monads. We thus 
use lists as the base monad, upon which other transformers 
can be applied. 

instance Monad List where 
unit x = [x] 

[ ] 'bind' k = [] 

(x : xs) 'bind' k = k x ++ (xs 'bind' k) 



class Monad m =3- ListMonad m where 
merge :: [m a] — > m a 

instance ListMonad List where 
merge = concat 

8 Lifting Operations 

We have introduced monad transformers that add useful 
operations to a given monad, but have not addressed how 
these operations can be carried through other layers of 
monad transformers, or equivalently, how a monad trans- 
former lifts existing operations within a monad. 

Lifting an operation / in monad m through a monad 
transformer f results in an operation whose type signature 
can be derived by substituting all occurrences of m in the 
type of /with "t m". For example, lifting "inEnv :: r — > m a 
— > m a" through f results in an operation with type "r — > tm 
a — > t m a." 

Given the types of operations in monad m: 

t ::= A (type constants) 

| a (type variables) 

I t — )■ t (function types) 

j (t, t) (product types) 

| m r (monad types) 

[]t is the mapping of types across the monad transformer f: 

\A] t = A 

\a] t = a 

\n -> rz\t = \n]t -> \rz\t 

\(n,T 2 )] t = (\n] t ,\r 2 ] t ) 

\m r] t = t m \r] t 

Moggi [15] studied the problem of lifting under a categor- 
ical context. The objective was to identify liftable operations 
from their type signatures. Unfortunately, many useful oper- 
ations such as merge, inEnv and callcc failed to meet Moggi's 
criteria, and were left unsolved. 

We individually consider how to lift these difficult cases. 
This allows us to make use of their definitions (rather than 
just the types), and find ways to lift them through all monad 
transformers studied so far. 

This is exactly where monad transformers provide us 
with an opportunity to study how various programming 
language features interact. The easy-to-lift cases correspond 
to features that are independent in nature, and the more 
involved cases require a deeper analysis of monad structures 
in order to clarify the semantics. 

An unfortunate consequence of our approach is that as we 
consider more monad transformers, the number of possible 
liftings grows quadratically. It seems, however, that there 
are not too many different kinds of monad transformers 
(although there may be many instances of the same monad 
transformer such as StateT). What we introduced so far 
are able to model almost all commonly known features of 
sequential languages. Even so, not all of them are strictly 
necessary. The environment, for example, can be simulated 
using a state monad: 

instance (Monad m, StateMonad r m) =>• 

EnvMonad r m where 
inEnv r m = update (\_ — > r) 'bind' \o — > 
m 'bind' \v — » 
update (\_ — » o) 'bind' \_ — » 
unit v 

rdEnv = update id 
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Also, as is well known, error reporting can be implemented 
using callcc. 

8.1 Correctness Criteria 

The basic requirement of lifting is that any program which 
does not use the added features should behave in the same 
way after a monad transformer is applied. The monad trans- 
former laws introduced in Section 7 are meant to guarantee 
such property for lifting a single computation. Most monad 
operations, however, have more general types. To deal 
with operations on arbitrary types, we extend Moggi's corre- 
sponding categorical approach, and define C T as the natural 
lifting of operations of type r along the monad transformer 
t: 



Cr 


:: T-*-|Y| t 




Ca 


= id 


(1) 


Ca 


= id 


(2) 




= \f -> f such that 




f ' = £-r 2 ' f 


(3) 




= \(a,b) (£ r , a,C Tl b) 


(4) 


£m t 


= lift ■ (map C T ) 


(5) 



Constant types (such as Integer) and type variables do not 
depend on any particular monad. (See cases 1 and 2.) On 
the other hand, we expect a lifted function, when applied 
to a value lifted from the domain of the original function, 
to return the lifting of the result of applying the original 
function to the unlifted value. This relationship is precisely 
captured by equation 3, which corresponds to the following 
commuting diagram: 

/' 

\n] t \r 2 ]t 



n j ~r 2 

The lifting of tuples is straightforward. Finally, the lift 
operator come with the monad transformer lifts computa- 
tions expressed in monad types. Note that C T is mapped 
to the result of the computation, which may involve other 
computations. 

Note that the above does not provide a Gofer definition 
for an overloaded lifting function C. The "such that" clause 
in the third equation specifies a constraint, rather than a 
definition of / . In practice, we first find out by hand how 
to lift an operation through a certain (or a class of) monad 
transformer, and then use the above equations to verify 
that such a lifting is indeed natural. Generally we require 
operations to be lifted naturally — although as will be seen, 
certain unnatural liftings change the semantics in interesting 
ways. 

8.2 Easy Cases 

Err and update are handled by lift, whereas merge benefits 
from List being the base monad. 

instance (ErrMonadm, MonadT t ra) =>• 

ErrMonad (t ra) where 

err = lift ■ err 



instance (StateMonad ra, MonadT t m) 

StateMonad (t ra) where 
update = lift ■ update 

instance MonadT t List =>• ListMonad (t List) where 
merge = join ■ lift 

8.3 Lifting Callcc 

The following lifting of callcc through EnvT discards the 
current environment r' upon invoking the captured contin- 
uation k. The execution will continue in the environment r 
captured when callcc was first invoked. 

instance (MonadT (EnvT r) ra, ContMonad ra) =>• 

ContMonad (EnvT r ra) where 

- - callcc :: ((a —>r—>mb)—>r—>ma)—>r—>ma 

callcc f = \r —t callcc (\k — » / (\a —t\r'—tk a) r) 

The Appendix shows that if we flip the order of monad 
transformers and apply ContT to "EnvT env m" — in which 
case no lifting of callcc will be necessary — the current 
environment will be passed to the continuation. (We will 
see how to fix this by carefully recovering the environment 
when we lift inEnv in a moment.) 

In general we can swap the order of some monad trans- 
formers (such as between StateT and EnvT), but doing so 
to others (such as ContT) may effect semantics. This is 
consistent with Filinski's observations [6], and, in practice, 
provides us an opportunity to fine tune the resulting seman- 
tics. 

In lifting callcc through "StateT s", we have a choice of 
passing either the current state s\ or the captured state so. 
The former is the usual semantics for callcc, and the latter is 
useful in Tolmach and Appel's approach to debugging [20]. 

instance (MonadT (StateT s) ra, ContMonad ra) =>• 

ContMonad (StateT s ra) where 

- - callcc :: ((a — > s — > ra (s,b)) — > s — > ra (s, a)) 

— > s — > ra (s,a) 
callcc f = \so -> callcc (\k — > 

/ (\a -> \si k (si, a)) so) 

The above shows the usual callcc semantics, and can be 
changed to the "debugging" version by instead passing (s o, 
a) to k. 

The lifting of inEnv through ErrorT can be found in the 
Appendix. 

8.4 Lifting InEnv 

We only consider lifting inEnv through ContT here; the 
Appendix shows how to lift inEnv through other monad 
transformers. 

instance (MonadT (ContT ans) ra, EnvMonadr ra) 

EnvMonad r (ContT ans ra) where 
inEnv r c = \k — » rdEnv 'bind' \o — » 

inEnv r (c (inEnv o ■ k)) 
rdEnv = lift rdEnv 

We restore the environment before invoking the continu- 
ation, sort of like popping arguments off the stack. On the 
other hand, an interesting (but not natural) way to lift inEnv 
is: 
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instance (MonadT (ContT ans) ra, EnvMonadr ra) =>• 

EnvMonad r (ContT ans ra) where 
inEnv r c = \k — » inEnv r (c k) 
rdEnv = lift rdEnv 

Here the environment is not restored when c invokes k, 
and thus reflects the history of dynamic execution. 

9 Conclusions 

We have shown how a modular monadic interpreter can 
be designed using two key ideas: extensible union types 
and monad transformers, and implemented using constructor 
classes. A key technical problem that we had to overcome 
was the lifting of operations through monads. Our ap- 
proach also helps to clarify the interactions between various 
programming language features. 

This paper realized Moggi's idea of a modular presen- 
tation of denotational semantics for complicated languages, 
and is much cleaner than the traditional approach [19]. On 
the practical side, our results provide new insights into 
designing and implementing programming languages, in 
particular, extensible languages, which allow the program- 
mer to specify new features on top of existing ones. 
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A The Ordering of ContT and EnvT 

It is interesting to compare the following two callcc functions 
on monad M and N, both composed from "ContT ans" and 
"EnvT m" , but in different order. 

Case 1: 

type M a = ContT ans (EnvT r ra) a 

= (a — > r — > ra ans) — > r — > ra ans 

callcc f = \k / (\a \_ k a) k 
(eta convert \r and \r') 
= \k \r f (\a — > \_ — > \r' — > k a r') k r 

Case 2: 

type M a = EnvT r (ContT ans ra) a 

= r -> (a -> m ans) — > ra ans 

callcc f = \r -> callcc (\k — > f (\a -> \r' -> k a) r) 
= \r -+\k (\k' / (\a ->\r' k' a) r) 

(\a — > \_ — > k a) k 
= \r \k f (\a — > \r' — > \_ — > k a) r k 

From the expansion of type M in case 1, we can see that 
both result and environment are passed to the continuation. 
When callcc invokes a continuation, it passes the current, 
rather than the captured continuation. The callcc function in 
case 2 works in the opposite way. 

B Lifting Callcc through ErrorT 

instance (MonadT ErrorT ra, ContMonad ra) 

ContMonad (ErrorT ra) where 
-- callcc :: ((a ^ m (Error a j) ^ m (Error a j) 
— > ra (Error a) 
callcc f = callcc (\k -> f (\a k (Ok a))) 

C Lifting InEnv through EnvT, StateT and ErrorT 

instance (MonadT (EnvT r') ra, EnvMonadr ra) =>• 

EnvMonadr (EnvT r' ra) where 
inEnv r ra = \r' — > inEnv r (ra r') 
rdEnv = lift rdEnv 

instance (MonadT (StateT s) ra, EnvMonad r ra) =>• 

EnvMonad r (StateT s ra) where 
inEnv r ra = \s — » inEnv r (ra s) 
rdEnv = lift rdEnv 

A function of type "m a — > m a" maps "m (Error flj" to 
"m (Error a)", thus inEnp stays the same after being lifted 
through ErrorT. 
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